查看原文
其他

Hadoop性能调优案例分享

2017-05-12 Coda6 大数据开放实验室

Hadoop作为一个庞大的系统,其调优的过程是很复杂的。Hadoop虽然提供了许多调优参数,但数量庞大,开发者往往难以做出合适选择,更凸显了调优的难度。本文将通过一则Hadoop调优案例,与读者分享一下如何从全局出发,根据资源的使用情况,合理的确定调优目标,梳理调优点,实现最终的性能优化。

测试案例介绍

TPCx-HS是TPC(http://www.tpc.org/)组织提供的Hadoop性能测试基准(http://www.tpc.org/tpcx-hs/default.asp),用于测试大数据平台硬件、软件和Hadoop文件系统API兼容软件,对它们的性能、性价比、可用性以及耗电性提供客观评估。TPCx-HS本质上是Hadoop的TeraSort benchmark,通过对TB级数据进行排序,来测试HDFS和MapReduce框架对大规模数据的处理性能。

TPCx HS由以下三部分组成:

  • TeraGen:生成大量用于排序的数据并放置在HDFS。此阶段只有Map,没有Reduce。

  • TeraSort:从HDFS上读取TeraGen生成的数据,用MapReduce框架进行排序,并把将结果放在HDFS。既有Map,也有Reduce。

  • Validate:排序结果验证,若任意文件没有按排序键正确排序,就报错。既有Map,也有Reduce。

优化前的测试

首先,我们在未进采用优化手段的情况下,进行了一轮TPCx-HS性能测试。结果显示,上述三项过程在测试中分别表现出以下特征:

  • TeraGen过程中,Map阶段的CPU负载较低,而网络是性能瓶颈。

  • TeraSort过程中,Map阶段的CPU以及Reduce阶段的网络都处于满负荷。

  • Validate的性能基本稳定,没有需要调优的地方。

所以我们的主要调优对象是TeraGen和TeraSort。

TeraGen的调优思路

TeraGen的性能瓶颈在于写HDFS 3副本时大量的网络吞吐。下图是运行时的网络负载情况:

根据上图,我们认为TeraGen性能调优要遵循下述基本思想:

  • 左边线的斜率要高。意味着Task要尽快启动,尽快完成任务。

  • 上面平台要平。即网络必须稳定且保持满负荷运转状态。

  • 右边线不能有拖尾。即任务量要均衡,单个Task处理的数据不能过多。

要满足这些要求,需要综合平衡各种因素和参数:

  • 通过提高各个服务间节点心跳的频率,加快Task的启动速度。

  • 基于对文件数目、TeraSort时的Map数目、以及TeraGen阶段每个Task的执行时间的考虑,选择合适的Block大小。

TeraSort的调优思路

TeraSort包含Map和Reduce两个阶段,其中Map阶段的CPU负载很高,但网络负载低;Reduce阶段的CPU负载很低,但网络负载很高。如果两个阶段顺序执行,势必有很多等待。

下图是TeraSort过程的CPU使用情况:

这是网络的使用情况:

从上图可见Map阶段基本没有网络负载,但是Reduce阶段网络负载很高,而且中间有明显下降,这说明Map和Reduce的重合度不够,且Reduce的数量较少。

基于对以上现象的观察,TeraSort性能调优的思想如下:

  • 为了减少Map到Reduce阶段的IO(数据量),中间的Shuffle过程需广播压缩后的数据。

  • 因为Map/Reduce阶段各自需要不同的资源,所以可以兼顾系统资源、Map和Reduce Task的数目,尽量让Map和Reduce重合。

  • 即使Map和Reduce重合,Map Task可能仍然占用大部分资源。为了处理更多数据,Reduce Task不能过多。

经过优化后的CPU负载情况如下:

 

网络负载情况如下:

Map/Reduce数目

Map和Reduce数目这两个参数对TeraGen和TeraSort的性能影响都非常大,需要仔细调试。下面以10T为例来说明。

首先要理清文件数、Split数目、Bloc 46 32133 46 14987 0 0 2231 0 0:00:14 0:00:06 0:00:08 2884k Size、MapTask数目之间的关系。

由于TeraGen过程不涉及HDFS读操作,所以设定的NUM_MAPS就是实际运行时Map Task的数目,于是最终写到HDFS上的文件个数就是Map Task数目。

如果只有一个文件,那么Split数目就等于filesize / blocksize。例如,假设我们选择采用1G的blocksize,对于数据量为10T的文件,Split的数目为:10,000, 000, 000 / 1,073,741,824 ~= 9314

此时的NUM_MAPS可为9314/3(NUM_MAPS = Split数目/N,N可以根据性能调整),约等于3105。

因为TeraSort是从HDFS上读数据的,所以Map Task数目由总的Split数目决定,和NUM_MAPS无关。Reduce Task的数目由NUM_REDUCERS决定。

硬件环境配置

  • CPU

    为了提高性能,CPU必须处于Performance模式,而不是PowerSave。另外还需要检查/proc/cpuinfo中的CPU主频,保证即使CPU空闲,主频也为2.XGHz.

  • 网络

    网络必须能够全速运行。可以用网络工具来检测网路速度。

  • 磁盘

    必须保证足够多的磁盘,如果磁盘吞吐量不够,磁盘IO将是整个测试过程的瓶颈。

总结

除了对上面内容涉及的参数修改,实际中我们在测试时还对内存、GC等参数进行了调整。

正如本文所描述的,Hadoop的调试过程要求开发者对架构底层有一定了解,需要能结合业务场景特征,理解资源图表,对不同数据集不同集群,利用不同相关参数的作用,实现性能优化。


往期原创文章

星环的划时代版本-Transwarp Data Hub 5.0

关于StreamSQL中的Application隔离

基于流的SQL引擎:StreamSQL(基础介绍)

大数据上的数据稽查原理和方法介绍(下)

大数据上的数据稽查原理和方法介绍(上)

ETL调优的一些分享(下)

ETL调优的一些分享(上)

揭秘Inceptor Server HA

从阅读量看大数据技术关注热点

如何让Kafka集群免受黑客攻击

Transwarp如何让Hadoop集群免受黑客攻击

SQL优化:基于代价的优化方法的介绍与使用(下)

SQL优化:基于代价的优化方法的介绍与使用(上)

Hadoop平台中SQL优化的四个思路

大数据基础技术的未来演进趋势预测




大数据开放实验室由星环信息科技(上海)有限公司运营,专门致力于大数据技术的研究和传播。若转载请在文章开头明显注明“文章来源于微信订阅号——大数据开放实验室”,并保留作者和账号介绍。


您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存